Making edits to `CREW_AIDS`

note

Prior to pulling the most recent version from, or commiting edits to the CREW_AIDS repo on the DIP, you will need to have completed the Initial Setup of the MIP with the DIP hosted Gitlab.

tip

See 262COS-GIT-SOP-004 - CREW_AIDS Development From a MIP for the full authoring guide - document standards, MDX best practices, rendering pitfalls, and the Git workflow.

Crew Aid Labeling Standard

info

Label Format

Full Label Format: <REFERENCE_CODE>_<TITLE>_<VERSION_DATE>

The <REFERENCE_CODE> is broken down into multiple parts -> <UNIT>-<CATEGORY>-<TYPE>-<SERIES> (see the full Label Breakdown below). It is used to quickly and uniquely identify what UNIT created the Crew Aid (262COS is implied), what topic or CATEGORY the Crew Aid relates to, the TYPE - or how it is expected to be used, as well as a SERIES number to differentiate unique Crew Aids of the same type.

Markdown File Structure:

The file structure of a markdown Crew Aid aligns to how they are presented in a web browser when hosted by Docusaurus. You will notice that the UNIT is not designated any where in any folder/file names as it will always be implied to be 262COS. The VERSION_DATE is also not designated any where in any folder/file names - this is inferred via the 00_introduction.md revision table when the CI/CD pipeline automatically processes each Crew Aid into a PDF.

CREW_AIDS/
└── <CATEGORY>/
    └── <TYPE>-<SERIES> - <TITLE>/
        ├── 00_introduction.md
        └── 01_procedures.md

This example markdown file structure equates to the label 262COS-DIP-SOP-001. The GitLab CI pipeline will parse the structure and convert this SOP into a PDF named 262COS-DIP-SOP-001_CVAH_3.7_DIP_Setup_2022.11.06.pdf - assuming that the first page "00_introduction.md" has a revision table, or 262COS-DIP-SOP-001_CVAH_3.7_DIP_Setup.pdf if it does not.

CREW_AIDS/
└── 02_DIP/
    └── SOP-001 - CVAH 3.7 DIP Setup/
        ├── 00_introduction.md
        └── 01_procedures.md

Label Breakdown

Full Label Format: <REFERENCE_CODE>_<TITLE>_<VERSION_DATE>

<REFERENCE_CODE>: A short string for quickly referencing and identifying the general purpose of a document - much like the Air Force technical order naming system.
Format: <UNIT>-<CATEGORY>-<TYPE>-<SERIES>
Example: 262COS-MIP-SOP-001

NOTE: This example reference code signifies that the document is a Standard Operating Procedure (SOP) developed by the 262COS that focuses on the MIP.

<UNIT>: Identifies the unit or organization that the document was published by.

<TYPE>: Identifies the document type. See the table below for definitions.

Type	Description
`SOP`	SOPs - Outline specific step-by-step procedures that must be followed in order to achieve a specific outcome.
`AID`	Aids - References or methodology guides for situations where a step-by-step SOP cannot be viably employed.
`CL`	Checklists - Normally reference SOPs for accomplishing task items within the list.

<CATEGORY>: A short string of characters to help identify the component, software, or process that the document pertains to. This string is usually an abbreviation or a shorthand for the component, software, or process. See the below table for pre-established IDs.

Category	Folder	Description
`EP`	00_EMERGENCY	Emergency procedures.
`PRE`	01_PRE_EXECUTION	Pre-mission, pre-sortie, and planning, or otherwise non-execution procedures and processes.
`DIP`	02_DIP	CVA/H DIP procedures. May contain procedures for individual tools, but not so much that the document is ID'd for the specific tool.
`MIP`	03_MIP	CVA/H MIP procedures. May contain procedures for individual tools, but not so much that the document is ID'd for the specific tool.
`COMM`	04_COMMUNICATION	Communication and task management tools, procedures, and processes.
`HA`	05_HOST_ANALYST	Host Analyst (HA) procedures, processes, or other activities that may combine the use of multiple tools.
`NA`	06_NETWORK_ANALYST	Network Analyst (NA) procedures, processes, or other activities that may combine the use of multiple tools.
`OPS`	07_OPERATIONS	General cyber operations procedures and analysis techniques that aren't specific to network/host activities.
`CTE`	08_CTE	Cyber Threat Emulation, penetration testing, or other red-team type activities.
`ICS`	09_ICS	ICS (Industrial Control System)/SCADA (Supervisory Control and Data Acquisition) related procedures and documentation.
`LEAD`	10_ELEMENT_LEAD	Mission Element Lead (MEL) processes and procedures.
`IA`	11_INTEL	Intel related procedures, and processes.
`ELK`	12_ELASTIC	Logstash, Elasticsearch, Kibana, or Beat specific procedures, and processes.
`MS`	13_METASPONSE	Metasponse specific procedures, and processes.
`SO`	14_SECURITY_ONION	Security Onion specific procedures, and processes.
`EG`	16_ENDGAME	Endgame specific procedures, and processes.
`GIT`	17_GIT	Git specific procedures, and processes.
`POST`	99_POST_EXECUTION	Post-mission, post-sortie, debriefing, and reconstitution or otherwise non-execution procedures, and processes.
`XX`	XX_*	Reserved for draft, archived, or template documents.

<SERIES>: An iterating number starting from 001 that signifies numbered document of the same TYPE and CATEGORY.
<TITLE>: A string to fully identify the purpose of the document. It is preferable to be kept short in order to avoid long filenames.
Example: CVA/H 3.6 DIP Setup (Custom 262COS Configuration)
<VERSION_DATE>: The date that the document was last revised and serves as for quick identification of how "new" a document's version is. This is only used for non-markdown documents.
Format: <YYYY.MM.DD>
Extended Format: <YYYY.MM.DD.##>
Example 1: 2022.11.16
Example 2: 2022.11.16.04

NOTE: This example version signifies that the document was last updated on November 11th, 2022 and was the 4th revision on that same day. For situations where a document is expected to be updated frequently within a single day (such as an evolving SOP that is revised multiple times during execution), an additional number is appended to the date to signify the Nth time that the document was updated during that same day, starting with ".01".

1. Create your own working `branch`

Change directories to the /cvah/git/CREW_AIDS project folder:
```
cd /cvah/git/CREW_AIDS
```
Ensure the remote named origin is pointing to the DIP Gitlab instance at https://gitlab/262-cos/CREW_AIDS
```
git remote -v
```
tip
If origin is not pointing to the correct location, you can change it with the following command:
git remote set-url origin https://gitlab/262-cos/CREW_AIDS
Pull the most recent changes of the main branch from the DIP Gitlab instance to your local repo:
```
git pull
```
NOTE: You can skip this step if you do not have a connection to the DIP Gitlab.
Create a new branch of the current snapshot of the main branch with name containing your username, then use checkout to switch to it:
```
git branch <YOUR_USERNAME>-edits
git checkout <YOUR_USERNAME>-edits
```
Publish your new branch to the DIP Gitlab:
```
git push --set-upstream origin <YOUR_USERNAME>-edits
```
NOTE: You can skip this step if you do not have a connection to the DIP Gitlab.

2. Verify the Dev Preview is Running

The MIP runs a crewaid-dev service that hosts a live Docusaurus dev preview at http://localhost:3000. It monitors /cvah/git/CREW_AIDS for file changes and reflects them automatically.

info

docusaurus hosts the CREW_AIDS in two different modes:

Serve: The crewaid service hosts the site in a mode that does not reflect changes until the service is restarted (takes 3-5 minutes to restart as it converts all markdown to a static HTML site).
Development: The crewaid-dev service renders each page individually in-memory and monitors for file changes. Markdown syntax errors and broken links are more lenient in this mode (they show up as error banners in the browser rather than crashing the whole site), and the search bar does not function.

caution

Broken links and some markdown syntax errors will cause the crewaid service to fail to start - ensure they are resolved before restarting the service or committing changes to the repository.

sudo systemctl status crewaid-dev

# If not running:
sudo systemctl start crewaid-dev

Navigate to http://localhost:3000 to view and monitor your changes as you edit.

3. Making changes in VS Code

Start VS Code and open the local CREW_AIDS repository:
```
code /cvah/git/CREW_AIDS
```
NOTE: You may be prompted to Trust the authors of all files in the parent folder 'git' - check the box and click Yes
Work on the repository as you see fit, using the VS Code Fundamentals page as a reference

Crew Aid Labeling Standard​

Label Format​

Label Breakdown​

1. Create your own working branch​

2. Verify the Dev Preview is Running​

3. Making changes in VS Code​